Conventional vertex processing for three-dimensional (3-D) graphics programming application program interfaces (APIs) such as Open Graphics Library (OpenGL®) and D3D™ provide support for per-vertex lighting, position transformation, and texture coordinate generation. The computations provided by such conventional vertex processing are routinely implemented by 3-D graphics hardware that greatly accelerates these operations.
One drawback of the aforementioned conventional vertex processing is that it is configurable, but not programmable. When using conventional vertex processing, an application can enable and disable various options, set transformation matrices, lighting, and texture coordinate generation parameters. However, such applications are limited to the set of computations provided by the conventional vertex processing feature set.
While the feature set has been gradually extended over time to support multiple texture units, and more texture coordinate generation modes and vertex blending schemes, the conventional vertex processing model is still fundamentally configurable, not programmable.
Conventional vertex processing assigns names to per-vertex quantities such as “position”, “color”, and “surface normal”. These names convey a sense of how the quantities are processed by conventional vertex processing. For example, surface normals are used for lighting vertices. The quantities' meaning is directly tied to the operations performed with the quantity by conventional vertex processing. Similarly, other quantities such as “light position”, “light color”, and “modelview matrix” are named to convey how these quantities are used by conventional vertex processing.
Existing applications use API commands named based on the conventions of conventional vertex processing. For example, a vertex may be set in the manner shown in Table 1.
TABLE 1glNormal3f(xnor, ynor, znor);glColor3f(red, green, blue);glVertex3f(xpos, ypos, zpos);
In contrast with conventional vertex processing, application-programmable vertex processing has no pre-existing meaning for the quantities used to process vertices. Instead, there is simply a predetermined amount of numbered per-vertex quantities (per-vertex variables) and a predetermined amount of state numbered quantities (per-vertex constants). How these quantities are used to process the vertices depends on the application-supplied vertex program's instruction sequence.
For example, a vertex would be set in the manner set forth in Table 1A.
TABLE 1AglVertexAttrib3fNV(2, xnor, ynor, znor);glVertexAttrib3fNV(3, red, green, blue);glVertexAttrib3fNV(0, xpos, ypos, zpos);
Prior art techniques for extending conventional vertex processing generally require adding more modes, state, and per-vertex attributes. This lead to per-vertex attributes beyond the standard OpenGL per-vertex attributes (position, normal, color, texture coordinates, etc). Examples of the new (extended) attributes are secondary color, fog coordinate, weights (for vertex blending), and additional texture coordinate sets.
While application-programmable vertex processing provides tremendous flexibility in comparison to conventional vertex processing, 3D applications must, however, assign their own meaning to vertex processing quantities rather than have meanings assigned by the conventions of conventional vertex processing. Because vertex programs assign the “meaning” to vertex attributes based on how the program uses the various vertex attributes, it makes little sense to give the vertex attributes conventional names. Application-programmable vertex processing considers vertex attributes “generic” numbered quantities. This distinction between convention-specified and program-specified semantics for vertex processing quantities presents a significant hurdle to integrating application-programmable vertex processing into existing applications.
There is thus a need for a set of API features that facilitate combining application-programmable vertex processing with existing 3D applications originally authored to use conventional vertex processing. There is a further need for API features that reduce the effort required to augment an existing 3D application to use application-programmable vertex processing.
There is a further need to enhance application-programmable vertex processing by expanding the functionality of a hardware-implemented graphics pipeline and optimizing the operation thereof.
Software emulators have traditionally been used to emulate the operation of various hardware devices. In conventional emulators, when an instruction that should be emulated is executed or when an address or I/O that should be emulated is accessed, this instruction, address or I/O is stored. Analysis is then performed as to what processes are to be executed, and a substitute routine prepared in advance is executed using functions of a specific central processing unit (CPU) so that the same result is obtained on the executing machine.
It would be beneficial to exploit emulator technology to achieve the aforementioned enhancements and optimizations during application-programmable vertex processing.